fix: post-0.14.1 flakefix + strict-mode init_or_die#78
Merged
Conversation
Closes the CI failure mode that run 30088911608 surfaced on the post-merge push to master after #77 (0.14.1 release). Two distinct problems in two commits: 1. **flakefix: ``@pytest.mark.rerunfailures`` wrong kwarg + tight release window.** The Sprint 0 (PR #76) follow-up shipped ``@pytest.mark.rerunfailures(max_retries=2)`` on ``tests/test_approval_timeout_field.py::TestApprovalTimeoutResolution ::test_env_fallback_when_server_value_is_zero``. That kwarg was deprecated in ``pytest-rerunfailures 15.x`` (the version pinned in ``dev``), so the marker was a no-op on CI and the release-window race stayed flaky. Two-part fix: * Use the documented ``reruns=2`` kwarg so the marker actually triggers a retry on the inner helper. * Widen ``release_after_ms`` from 50ms to 200ms. Still well below the 120s env default timeout so the test stays fast on CI, but enough headroom that the spawned worker thread reliably reaches ``event.wait()`` before the main thread fires the WS release. 2. **strict-mode survives ``init_or_die()`` reinit** (commit ``5354e86``, surfaced on branch ``fix/gap-1c-approval-timeout`` after PR #76 was merged). The pre-fix code had a four-cell state space (extractor present × runtime registry has the tool name) for the sensitive-tool check. The ``@sensitive(impact=...)`` decorator stamped ``_nullrun_extractor`` on the @Protect wrapper (not on the user function), so a reinit that tore down the wrapper broke the lookup. The fix pins ``_nullrun_extractor`` to the runtime registry as well so a reinit that replaces the wrapper still finds the extractor. Verification: * ``pytest -n auto --cov=src/nullrun --cov-branch --cov-report=xml --cov-fail-under=0`` -> 1367 passed, 7 skipped, 29 warnings in 34.54s, coverage 81.45%. * ``ruff check src/ tests/`` -> All checks passed. * ``mypy src/`` -> Success: no issues found in 36 source files. Diff vs origin/master: +191/-19 across 4 files (``src/nullrun/decorators.py``, ``src/nullrun/runtime.py``, ``src/nullrun/transport.py``, ``tests/test_approval_timeout_field.py``). No SDK_MIN_VERSION bump. No on-wire change. No public API change.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the CI failure mode that run 30088911608 surfaced on the post-merge push to master after #77 (0.14.1 release). Two distinct problems in one squash commit.
1. flakefix:
@pytest.mark.rerunfailureswrong kwarg + tight release windowThe Sprint 0 (PR #76) follow-up shipped
@pytest.mark.rerunfailures(max_retries=2)ontests/test_approval_timeout_field.py::TestApprovalTimeoutResolution::test_env_fallback_when_server_value_is_zero. That kwarg was deprecated inpytest-rerunfailures 15.x(the version pinned indev), so the marker was a no-op on CI and the release-window race stayed flaky.Two-part fix:
reruns=2kwarg so the marker actually triggers a retry on the inner helper.release_after_msfrom 50ms to 200ms. Still well below the 120s env default timeout so the test stays fast on CI, but enough headroom that the spawned worker thread reliably reachesevent.wait()before the main thread fires the WS release.2. strict-mode survives
init_or_die()reinitSurfaced on branch
fix/gap-1c-approval-timeoutafter PR #76 was merged as squash0092d11. The pre-fix code had a four-cell state space (extractor present × runtime registry has the tool name) for the sensitive-tool check. The@sensitive(impact=...)decorator stamped_nullrun_extractoron the@protectwrapper (not on the user function), so a reinit that tore down the wrapper broke the lookup. The fix pins_nullrun_extractorto the runtime registry as well so a reinit that replaces the wrapper still finds the extractor.Verification
Compatibility
Diff vs origin/master: +191/-19 across 4 files (
src/nullrun/decorators.py,src/nullrun/runtime.py,src/nullrun/transport.py,tests/test_approval_timeout_field.py).